Skip to content

Introduce debuginfo to statements in MIR #142771

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

dianqk
Copy link
Member

@dianqk dianqk commented Jun 20, 2025

The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix #128081.

I don't modify Stable MIR, as I don't think we need debug information when using it.

This PR represents the debug information for the dead reference statement via #dbg_value. For example, let _foo_b = &foo.b becomes #dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26). You can see this here: https://rust.godbolt.org/z/d43js6adv.

The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.

The current rules for dropping debug information in this PR are:

I haven't drop debuginfos in MatchBranchSimplification, because LLVM also pick one branch for it.

For the perf result:

I expected this to introduce some regressions; however, the results mixed the effects of inlining. Looking at the doc profile, this is a clear optimization. One potential regression I'm investigating is serde-1.0.219-debug-full.

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 20, 2025
@rust-log-analyzer

This comment has been minimized.

@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 15c968a to 6b013d4 Compare June 20, 2025 08:01
@rust-log-analyzer

This comment has been minimized.

@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 6b013d4 to 51576e7 Compare June 20, 2025 09:23
@rust-log-analyzer

This comment has been minimized.

@dianqk
Copy link
Member Author

dianqk commented Jun 20, 2025

@bors2 try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jun 20, 2025

⌛ Trying commit 51576e7 with merge eb83156

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jun 20, 2025
Introduce debuginfo to statements in MIR

Not ready for reviewing. Something known:

- [ ] Retain debuginfo when concatenating bbs
- [ ] Document about when to drop debuginfos (don't be worse than the optimized LLVM IR)
- [ ] Missing tests

r? ghost
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 20, 2025
@rust-bors
Copy link

rust-bors bot commented Jun 20, 2025

☀️ Try build successful (CI)
Build commit: eb83156 (eb83156169ae3bbdd1385d498455dbc44283f5ff, parent: 18491d5be00eb3ed2f1ccee2ac5b792694f2a7a0)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (eb83156): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.9% [0.2%, 14.5%] 51
Regressions ❌
(secondary)
0.8% [0.1%, 1.6%] 52
Improvements ✅
(primary)
-0.4% [-2.1%, -0.2%] 35
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.2%] 39
All ❌✅ (primary) 0.4% [-2.1%, 14.5%] 86

Max RSS (memory usage)

Results (primary 2.3%, secondary 3.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.3% [0.8%, 4.7%] 54
Regressions ❌
(secondary)
3.6% [0.7%, 7.4%] 38
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.3% [-3.3%, -3.3%] 1
All ❌✅ (primary) 2.3% [0.8%, 4.7%] 54

Cycles

Results (primary 3.2%, secondary 2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.9% [1.1%, 14.4%] 7
Regressions ❌
(secondary)
2.5% [2.0%, 3.3%] 3
Improvements ✅
(primary)
-2.0% [-2.0%, -2.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.2% [-2.0%, 14.4%] 8

Binary size

Results (primary 0.5%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.7% [0.0%, 2.2%] 123
Regressions ❌
(secondary)
1.1% [0.0%, 3.5%] 59
Improvements ✅
(primary)
-0.9% [-6.5%, -0.1%] 11
Improvements ✅
(secondary)
-0.5% [-13.0%, -0.1%] 55
All ❌✅ (primary) 0.5% [-6.5%, 2.2%] 134

Bootstrap: 691.482s -> 692.445s (0.14%)
Artifact size: 371.94 MiB -> 372.12 MiB (0.05%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jun 20, 2025
@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 51576e7 to e72c3ae Compare June 21, 2025 02:31
@dianqk
Copy link
Member Author

dianqk commented Jun 21, 2025

@bors2 try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jun 21, 2025

⌛ Trying commit e72c3ae with merge 77d5c6a

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jun 21, 2025
Introduce debuginfo to statements in MIR

Not ready for reviewing. Something known:

- [ ] Retain debuginfo when concatenating bbs
- [ ] Document about when to drop debuginfos (don't be worse than the optimized LLVM IR)
- [ ] Missing tests

r? ghost
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 21, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jun 21, 2025

☀️ Try build successful (CI)
Build commit: 77d5c6a (77d5c6a20a77fabdee3790a412618b82178e9ab4, parent: 15c701fbc995eb6c5b3a86021c18185f8eee020d)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (77d5c6a): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.9% [0.1%, 14.5%] 53
Regressions ❌
(secondary)
0.8% [0.1%, 1.6%] 50
Improvements ✅
(primary)
-0.4% [-3.0%, -0.2%] 46
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.2%] 41
All ❌✅ (primary) 0.3% [-3.0%, 14.5%] 99

Max RSS (memory usage)

Results (primary 2.4%, secondary 3.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.4% [0.5%, 5.7%] 38
Regressions ❌
(secondary)
4.2% [1.3%, 6.2%] 25
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.7% [-3.0%, -1.1%] 4
All ❌✅ (primary) 2.4% [0.5%, 5.7%] 38

Cycles

Results (primary 2.1%, secondary 0.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.0% [0.8%, 14.1%] 10
Regressions ❌
(secondary)
3.3% [2.3%, 4.3%] 2
Improvements ✅
(primary)
-2.3% [-2.9%, -1.7%] 2
Improvements ✅
(secondary)
-2.2% [-2.6%, -1.9%] 2
All ❌✅ (primary) 2.1% [-2.9%, 14.1%] 12

Binary size

Results (primary 0.5%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.7% [0.0%, 3.0%] 122
Regressions ❌
(secondary)
1.1% [0.0%, 3.5%] 59
Improvements ✅
(primary)
-0.7% [-4.9%, -0.0%] 15
Improvements ✅
(secondary)
-0.5% [-12.7%, -0.0%] 55
All ❌✅ (primary) 0.5% [-4.9%, 3.0%] 137

Bootstrap: 690.617s -> 691.47s (0.12%)
Artifact size: 371.83 MiB -> 372.01 MiB (0.05%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 21, 2025
@bors
Copy link
Collaborator

bors commented Jun 25, 2025

☔ The latest upstream changes (presumably #142870) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

bug!("debuginfo is not yet supported.")
}
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder: should we attempt to keep debuginfo in most cases, and only drop statements that we do not know how to convert? I mean, consider drop_debuginfo to be always false, and replace the bug! by a no-op?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to do this after we've reviewed most of the MIR statements.

@@ -62,16 +64,22 @@
+ StorageLive(_8);
+ StorageLive(_9);
+ StorageLive(_11);
+ _11 = copy (((((*_6).0: alloc::raw_vec::RawVec<A>).0: alloc::raw_vec::RawVecInner).0: std::ptr::Unique<u8>).0: std::ptr::NonNull<u8>);
+ _9 = copy _11 as *mut A (Transmute);
+ // DBG: AssignRef(_11, ((*_6).0: alloc::raw_vec::RawVec<A>))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: could you make this a little more pretty? Reuse the _11 = &stuff syntax?

data.retain_statements(|statement| {
let keep = match &statement.kind {
for statement in data.statements.iter_mut() {
let drop_debuginfo = match &statement.kind {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be more readable as a let (keep_statement, drop_debuginfo) = ? Instead of short-circuit inside the match?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -52,7 +52,7 @@ impl<'tcx> crate::MirPass<'tcx> for CopyProp {
Replacer { tcx, copy_classes: ssa.copy_classes(), fully_moved, storage_to_remove }
.visit_body_preserves_cfg(body);

crate::simplify::remove_unused_definitions(body);
crate::simplify::remove_unused_definitions(body, false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we reason according to mir-opt-level, or the debuginfo the user requires like the inliner does?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated it on c6220a4.

.after_last_stmt_debuginfos
.extend_from_slice(&debuginfos);
}
debuginfos.extend_from_slice(&self.basic_blocks[current].after_last_stmt_debuginfos);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this directly extend pred_debuginfos?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a new revision that directly extends pred_debuginfos.

Comment on lines 160 to 166
let mut debuginfos = if let Some(first_succ) = terminator.successors().next()
&& terminator.successors().all(|s| s == first_succ)
{
Some(Vec::new())
} else {
None
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, you only add debuginfo if all successors are the same. Do you mind adding a comment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +193 to +197
parent_bb_last_debuginfos.append(&mut stmt.debuginfos);
std::mem::swap(&mut parent_bb_last_debuginfos, &mut stmt.debuginfos);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment explaining this is a faster version of a "prepend"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot find the "prepend" method. :?

// CHECK-LABEL: fn drop_debuginfo
// CHECK: debug foo_b => [[foo_b:_[0-9]+]];
// CHECK: bb0: {
// CHECK-NEXT: DBG: AssignRef([[foo_b]], ((*_1).1: i64))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a CHECK-NOT for the absence of the other debuginfo statement? Eventually a comment stating why we expect that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's enough to use CHECK-NEXT already here. The latest commit includes a comment.

@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 0989b8f to 05e7608 Compare July 13, 2025 15:21
@rust-log-analyzer

This comment has been minimized.

@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 05e7608 to 910cac7 Compare July 14, 2025 00:44
@dianqk
Copy link
Member Author

dianqk commented Jul 14, 2025

@bors2 try @rust-timer queue

@rust-timer

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Jul 14, 2025
Introduce debuginfo to statements in MIR

The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix #128081.

I don't modify Stable MIR, as I don't think we need debug information when using it.

This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.

The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.

The current rules for dropping debug information in this PR are:

- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.

> I haven't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.

For [the perf result](#142771 (comment)):

I expected this to introduce some regressions;  however, the results mixed the effects of inlining. Looking at the doc profile, this is a clear optimization. One potential regression I'm investigating is `serde-1.0.219-debug-full`.
@rust-bors
Copy link

rust-bors bot commented Jul 14, 2025

⌛ Trying commit 910cac7 with merge 91b1a3e

To cancel the try build, run the command @bors2 try cancel.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 14, 2025
@rust-bors
Copy link

rust-bors bot commented Jul 14, 2025

☀️ Try build successful (CI)
Build commit: 91b1a3e (91b1a3e3ba6355bd6e26493f0e529bec9b45c616, parent: 9c3064e131f4939cc95a29bb11413c49bbda1491)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (91b1a3e): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.6% [0.2%, 3.2%] 58
Regressions ❌
(secondary)
0.7% [0.1%, 1.8%] 67
Improvements ✅
(primary)
-0.3% [-1.9%, -0.1%] 65
Improvements ✅
(secondary)
-0.3% [-0.7%, -0.0%] 67
All ❌✅ (primary) 0.1% [-1.9%, 3.2%] 123

Max RSS (memory usage)

Results (primary 2.1%, secondary 2.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.1% [0.6%, 4.7%] 55
Regressions ❌
(secondary)
3.7% [1.3%, 6.1%] 33
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-3.5%, -1.1%] 5
All ❌✅ (primary) 2.1% [0.6%, 4.7%] 55

Cycles

Results (primary 2.6%, secondary 5.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.6% [2.6%, 2.6%] 1
Regressions ❌
(secondary)
5.8% [2.6%, 10.6%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.6% [2.6%, 2.6%] 1

Binary size

Results (primary 0.5%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.7% [0.0%, 2.0%] 116
Regressions ❌
(secondary)
1.1% [0.0%, 3.5%] 57
Improvements ✅
(primary)
-0.7% [-6.3%, -0.1%] 15
Improvements ✅
(secondary)
-0.5% [-12.7%, -0.1%] 57
All ❌✅ (primary) 0.5% [-6.3%, 2.0%] 131

Bootstrap: 462.57s -> 466.721s (0.90%)
Artifact size: 374.65 MiB -> 374.70 MiB (0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 14, 2025
@dianqk dianqk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 14, 2025
@dianqk dianqk force-pushed the mir-stmt-debuginfo branch from 910cac7 to 3a1ab06 Compare July 16, 2025 00:03
@dianqk
Copy link
Member Author

dianqk commented Jul 16, 2025

@bors2 try @rust-timer queue

@rust-bors
Copy link

rust-bors bot commented Jul 16, 2025

⌛ Trying commit 3a1ab06 with merge 9f0ec68

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jul 16, 2025
Introduce debuginfo to statements in MIR

The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix #128081.

I don't modify Stable MIR, as I don't think we need debug information when using it.

This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.

The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.

The current rules for dropping debug information in this PR are:

- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.

> I haven't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.

For [the perf result](#142771 (comment)):

I expected this to introduce some regressions;  however, the results mixed the effects of inlining. Looking at the doc profile, this is a clear optimization. One potential regression I'm investigating is `serde-1.0.219-debug-full`.
@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 16, 2025
@rust-bors
Copy link

rust-bors bot commented Jul 16, 2025

☀️ Try build successful (CI)
Build commit: 9f0ec68 (9f0ec689777f59dbfda5167d583b5785427ad06e, parent: 3014e79f9c8d5510ea7b3a3b70d171d0948b1e96)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (9f0ec68): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.6% [0.2%, 3.3%] 57
Regressions ❌
(secondary)
0.8% [0.1%, 2.0%] 60
Improvements ✅
(primary)
-0.4% [-1.2%, -0.1%] 79
Improvements ✅
(secondary)
-0.6% [-2.0%, -0.0%] 73
All ❌✅ (primary) 0.0% [-1.2%, 3.3%] 136

Max RSS (memory usage)

Results (primary 2.3%, secondary 3.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.3% [0.7%, 8.2%] 68
Regressions ❌
(secondary)
3.7% [1.1%, 6.3%] 33
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-3.7%, -1.7%] 4
All ❌✅ (primary) 2.3% [0.7%, 8.2%] 68

Cycles

Results (primary -0.3%, secondary -2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.8% [2.8%, 2.8%] 1
Regressions ❌
(secondary)
3.1% [3.1%, 3.1%] 1
Improvements ✅
(primary)
-3.3% [-3.3%, -3.3%] 1
Improvements ✅
(secondary)
-5.5% [-6.1%, -5.0%] 2
All ❌✅ (primary) -0.3% [-3.3%, 2.8%] 2

Binary size

Results (primary 0.5%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.7% [0.1%, 2.0%] 112
Regressions ❌
(secondary)
1.1% [0.0%, 3.5%] 58
Improvements ✅
(primary)
-0.5% [-6.5%, -0.1%] 20
Improvements ✅
(secondary)
-0.5% [-12.7%, -0.1%] 56
All ❌✅ (primary) 0.5% [-6.5%, 2.0%] 132

Bootstrap: 465.928s -> 464.642s (-0.28%)
Artifact size: 374.79 MiB -> 374.37 MiB (-0.11%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. perf-regression Performance regression. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bad codegen for non-copy-derived struct with all Copy derived fields
8 participants